Issue 85 add availability api endpoints #90
Conversation
|
I will add another endpoint /rooms/availability to quickly get all rooms' availibity with a date time filter. |
…T. Update validation for parameters date format and date range. Date range must be <= 42 days (suppose 6 lines X 7 days in calendar).
There was a problem hiding this comment.
Pull request overview
This PR adds two new availability API endpoints for meeting rooms: one that returns boolean availability for multiple rooms (whether they can be booked within a time range), and another that returns detailed available time slots for a single room grouped by date.
Changes:
- Added
/rooms/availabilityendpoint for paginated boolean availability across multiple rooms - Added
/rooms/{id}/availabilityendpoint for detailed time slot availability for a single room - Implemented recurrence rule handling for both rooms and bookings to calculate available time slots
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 13 comments.
| File | Description |
|---|---|
| server/api/room/views.py | Added helper functions and two new action methods for availability endpoints with logic to calculate free time slots by subtracting booked intervals from room schedules |
| server/api/room/tests.py | Added comprehensive test suite covering various scenarios including recurrence rules, timezone handling, and edge cases |
| server/api/room/README.md | Added API documentation for the two new availability endpoints with query parameters and examples |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
server/api/room/views.py
Outdated
| bookings = Booking.objects.filter(room=room).filter( | ||
| Q(recurrence_rule__isnull=False) | | ||
| Q(start_datetime__lt=end_datetime, end_datetime__gt=start_datetime) |
There was a problem hiding this comment.
The booking query logic has a potential issue. The query uses an OR condition where it fetches bookings with recurrence rules OR bookings that overlap the datetime range. However, bookings with recurrence rules should also be checked for whether they overlap the datetime range based on their base start/end times. A recurring booking that has occurrences in the requested range but whose base datetime is outside the range will still be fetched and processed, which could include irrelevant occurrences. Consider restructuring the query or adding additional filtering logic to handle this case more efficiently.
| bookings = Booking.objects.filter(room=room).filter( | |
| Q(recurrence_rule__isnull=False) | | |
| Q(start_datetime__lt=end_datetime, end_datetime__gt=start_datetime) | |
| bookings = Booking.objects.filter( | |
| room=room, | |
| start_datetime__lt=end_datetime, | |
| end_datetime__gt=start_datetime, |
There was a problem hiding this comment.
However, bookings with recurrence rules should also be checked for whether they overlap the datetime range based on their base start/end times. => Not true. For example, the start_datetime and end_datetime can all be in 20260101 but the booking lasts a year.
However, it reminds me that only confirmed booking should be in it, i.e., .filter(room=room, status="CONFIRMED")
server/api/room/views.py
Outdated
| results.append({"room_id": room.id, "availability": True}) | ||
| # If end_datetime is earlier than now, the room cannot be booked | ||
| elif end_datetime < current_time: | ||
| for room in page: | ||
| results.append({"room_id": room.id, "availability": False}) | ||
| else: | ||
| for room in page: | ||
| availability = self._calculate_boolean_availability(room, start_datetime, end_datetime) |
There was a problem hiding this comment.
Inactive rooms are not filtered out before calculating availability in the get_rooms_availability endpoint. While unauthenticated users will only see active rooms (via get_queryset), authenticated users could see inactive rooms marked as available, which is inconsistent with the behavior in get_room_availability (line 146-147) that returns empty availability for inactive rooms. Consider adding a check for room.is_active before calculating availability, or filtering inactive rooms as unavailable for consistency.
| results.append({"room_id": room.id, "availability": True}) | |
| # If end_datetime is earlier than now, the room cannot be booked | |
| elif end_datetime < current_time: | |
| for room in page: | |
| results.append({"room_id": room.id, "availability": False}) | |
| else: | |
| for room in page: | |
| availability = self._calculate_boolean_availability(room, start_datetime, end_datetime) | |
| # Inactive rooms should not be considered available | |
| availability = bool(room.is_active) | |
| results.append({"room_id": room.id, "availability": availability}) | |
| # If end_datetime is earlier than now, the room cannot be booked | |
| elif end_datetime < current_time: | |
| for room in page: | |
| results.append({"room_id": room.id, "availability": False}) | |
| else: | |
| for room in page: | |
| # Inactive rooms have no availability | |
| if not room.is_active: | |
| availability = False | |
| else: | |
| availability = self._calculate_boolean_availability( | |
| room, | |
| start_datetime, | |
| end_datetime, | |
| ) |
…s and room activeness.
Change Summary
/rooms/{id}/availability: Returns availabile slots for a single room grouped by date
/rooms/availability: Returns paginated results of availability for multiple rooms (in the sense that whether they can be booked within a time range) => which I think it is useful after starting to implement #24
Change Form
Fill this up (NA if not available). If a certain criteria is not met, can you please give a reason.
Other Information
Assumption:
To do:
Related issue